A common practice in the art of computer architecture is to move frequently performed and computationally intensive operations from the CPU to a special purpose functional unit, such as a graphics controller. The graphics controller is typically a separate integrated circuit (“chip”). In a computer system with a graphics controller, the graphics controller handles various tasks associated with displaying images on a display (such as converting primitive data to pixels), freeing the CPU to perform other tasks. Moving graphics operations from the CPU to the graphics controller improves the performance of the computer system. In practice, however, the amount of improvement is generally not as great as expected. The reason is that the transfer of data between the CPU and the graphics controller becomes a bottleneck that places a limit on the amount of performance improvement that can be realized. To illustrate the effect of the data transfer bottleneck, consider that in a typical computer system the CPU theoretically requires only 2 bus clock cycles (“BCLKs”) to perform a memory write command and a minimum of 4 BCLKs to perform a memory read command. In practice, however, writing to a prior art graphics controller requires 5 BCLKs and reading requires up to 8 BCLKs. During the 3-4 additional BCLKs that are required with a prior art graphics controller, the CPU does not perform any useful work. Accordingly, to fully realize the benefits of the graphics controller, there is a need to optimize data transfer between the CPU and the graphics controller.
The transfer of data between a CPU and a graphics controller involves a number of steps. These steps must be coordinated so that data is not transferred to the graphics controller faster than it can accept it and so that the CPU knows when data it has requested is available. To regulate the flow of data between the CPU and the graphics controller, the graphics controller includes a read/write control circuit that can be defined as a read/write state machine.
The read/write state machine typically has four states: An “idle” state in which the graphics controller waits for a request from the CPU; a “pause” state in which the graphics controller checks to make sure that any previous memory cycle is complete; a “request” state in which the graphics controller begins processing the memory cycle; and, an “end” state in which the graphics controller finishes processing the memory cycle. The read/write state machine transitions from state to state in a fixed sequence for each memory cycle. When the read/write state machine receives a request for a memory cycle, it moves sequentially from the idle state to the pause state to the request state to the end state. From the end state, the read/write state machine returns to the idle state where it waits for the next request for a memory cycle. During certain types or sequences of memory cycles, the read/write state machine may stay in one or more states for a longer period, but the basic state transition sequence does not change.
While the read/write state machine effectively regulates a single memory cycle, a problem arises when the CPU issues a series of consecutive commands for memory cycles. Because the state transition sequence must be fully complete before the CPU can issue a subsequent command, the CPU must wait to send a new command. This means that each command in a series of consecutive commands consumes more BCLKs than the CPU minimally requires. Because the CPU does not perform any useful work while it waits for the state transition sequence to complete, the prior art read/write state machine degrades the overall performance of the computer system.
Accordingly, there is a need for a high performance graphics controller that regulates the transmission of command information between the CPU and the graphics controller in such a way that the time that the CPU is required to wait before it can issue a new command is minimized.